o 



ON 



Integrating multiple sources to answer questions 
in Algebraic Topology/ 

Jonathan Heras, Vico Pascual, Ana Romero, and Julio Rubio 

Departamento de Matematicas y Computation, Universidad de La Rioja, 

Edificio Vives, Luis de Ulloa s/n, E-26004 Logroiio (La Rioja, Spain). 

{Jonathan. heras, vico. pascual, ana.romero, Julio .rubio}@unirioja.es 

Abstract. We present in this paper an evolution of a tool from a user 



interface for a concrete Computer Algebra system for Algebraic Topology 

*~7* (the Kenzo system), to a front-end allowing the interoperability among 

"^i different sources for computation and deduction. The architecture allows 

i- the system not only to interface several systems, but also to make them 

^vi cooperate in shared calculations. 

O 1 Different questions, different sources 

GO 

c/3 When "working in Mathematics, usually the researcher uses different sources of 

information. Typically, he can consult some papers or textbooks, make some 

computations with a Computer Algebra system, check the results against some 

t-H known tables or, more rarely, verify some conjectures with a proof assistant tool. 

That is to say, Mathematical Knowledge is dispersed among several sources. 

Our aim in this work is to mechanize, in some particular cases, the man- 
agement of these multiple-source information systems. Since it would be too 



f— ^ pretentious to try to solve fully this problem, we work in a very specific context. 

( " Thematically, we restrict ourselves to (a subset of) Algebraic Topology. With 

f» ^ respect to the sources, in order to have a representation wide enough, we have 

C^) chosen two Computer Algebra systems (Kenzo and GAP), a theorem prover 

t-H (ACL2) and a small expert system developed by us. The objective of the expert 

^. system is computing homotopy groups. Kenzo and GAP can compute homology 

• *h groups of different spaces, but the calculation of homotopy is in general much 

rS harder. Our homotopy expert system tries to take profit of theoretical knowl- 

edge contained in theorems (tables have been excluded up to now, since they 
are considered less difficult to integrate, from a technological point of view), and 
can ask computational results to Kenzo, if needed. 

This paper is a natural continuation of [17] and [18]. There are three main 
contributions in the paper: an architecture based on the Broker pattern [8] 
(proven as an open, flexible and adaptable tool); an Homotopy Expert System 
(HES) that allows non-trivial computations (and explanations) interacting with 
Kenzo; and the automation of the interoperability between Kenzo and GAP. 
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From the symbolic computation literature, we looked for inspiration in differ- 
ent projects and frameworks such as the MathWeb software bus [5], its successor 
the MathServe Framework [4], the MoNET project [9,6] or the MathBrokcr [2] 
and MathBrokcr II [3] projects, as well as in other works as [13] or [22]. 

2 General view of the system 

The Broker architectural pattern [8] can be used to structure software systems 
with decoupled components that interact through service invocations. The Bro- 
ker pattern defines three kinds of participants: clients, components, and the bro- 
ker itself. A scheme of our architecture based on this pattern is depicted in 
Figure 1. The mediator (broker) component embeds an Internal Memory where 
a strategy of memoization has been systematically implemented (based on the 
same idea used in GAP for attributes, see [16]). The system stores the results 
in the internal memory when a computation is executed for the first time, and 
if the same computation is asked again later, the result is simply looked up and 
returned, without further computation. 
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Fig. 1. Broker architectural pattern 



The decorator pattern [8] is used to wrap objects of our system with infor- 
mation, like the type of the object (simplicial set, group,. . . ) or the reduction de- 
gree [17] if the object is a topological space. This information guides the mediator 
to decide which component to use. Namely, Kenzo [11] (a Symbolic Computation 
system devoted to Algebraic Topology) is the core for computations related to 
homology groups of spaces, GAP [1] (a Computer Algebra system in the area 
of Computational Group Theory) and HAP [12] (a GAP homological algebra 
library) are the core for computations related to group homology, ACL2 [19] 
(a first order logic theorem prover) is the kernel for verifying the correctness of 
statements and, finally, the Homotopy Expert System (a small module devel- 
oped by us described in the next paragraph and from now on called HES) is in 
charge of computing homotopy groups. 

HES is a rule-based expert system. The structure of a rule-based expert sys- 
tem, see [15], consists of, and the HES is no exception, the following components: 
the Working memory (the facts), the Knowledge base (the rules), the Inference 
engine, a Knowledge acquisition module and an Explanation facility module. In 
the scope of the HES, the facts are properties associated with the objects (for 
instance, "Vn e N : A n is a contractible space"). The current knowledge base is 



made up of 23 rules (such as, "if X is contractible and n > 1 then 7r„(X) = 0"). 
The inference engine uses the forward chaining method for reasoning, see [15]. 
To grapple with the knowledge acquisition aspects, the HES takes profit from 
both the RulcML markup language [7] and the OMDoc format [20], the former 
one is used to specify rules in a declarative way and the second one to store 
concrete functionalities. Last but not least, gathering the applied rules and the 
facts that decorate each object, our HES is able to provide a trace containing 
the reasoning followed by it in order to reach a conclusion. 

However, the power of our system does not lie in gathering several computer 
algebra systems and theorem provers and use them separately with the same 
front end, but interconnecting them to reach new results. The communication 
among modules is performed by means of the OpenMath language [10], used to 
represent the objects in a common language for all the systems. 

In [21] an approach to coordinate GAP and Kenzo was presented. In that 
work GAP and Kenzo cooperate in order to compute homology groups of some 
spaces. These spaces with their homology can then be used in other construc- 
tions and applications. Some enhancements of that tool provided by our system 
are: avoidance of the installation of several programs and packages, automation 
of communication steps (here the SCSCP protocol [14] plays a key role) and 
concealment of the details to mix the systems. 

The general procedure and technology to connect with the ACL2 system 
explained in [18] is now applied to the context of group homology. The Common 
Lisp code used in Kenzo to represent a group is sent to ACL2 as an instance 
of an ACL2 encapsulate (a mechanism to introduce new functions symbols by 
axioms constraining them to have certain properties) by means of our broker, 
which is also in charge of invoking ACL2 in a way transparent for the user. 

In another line, Kenzo and the HES cooperate to compute homotopy groups 
of spaces. In this case, the HES requests Kenzo to compute homology groups 
which can be used to obtain homotopy groups. Whereas Kenzo communicates 
with the HES in order to send it results. The idea consists of gathering the 
knowledge stored in the HES and chaining several tools available in Kenzo to 
get results which are not reachable by anyone of them working in an independent 
way. 

3 Putting all together 

Our current front-end has evolved from the user interface for Kenzo presented 
in [17]. Its presentation layer is kept, but its internal mediator has been enriched 
to support different sources of information. Figure 2 displays some computations 
which took profit of the following interactions: Hi(fi 2 (S 4 )) = Z (computed with 
Kenzo), H 5 (C 5 ) = Z/5Z (computed with GAP), tt 4 (Z\ 4 x A 5 ) = (obtained with 
the Homotopy Expert System), H 5 (K(C\, 1)) = Z/5Z (computed with Kenzo + 
GAP), ^(S* 4 ) = Z (obtained with the Homotopy Expert System + Kenzo). 

It is worth noting that all results are shown to the user in a unique screen and 
that the computations are asked from a sole menu, then the user does not know 
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Fig. 2. The front end for computations 



the system in charge of computing neither the collaboration among computer 
algebra systems, he only receives the desired result. The technical details are 
hidden to the user. The results related to ACL2 are shown in a different tab to 
split the computations from the deductions. 



4 Conclusions and Further Work 



In this paper an architecture to integrate different tools for computing and log- 
ical reasoning in Algebraic Topology is presented. Even if our proposal has a 
limited extend, both thematically and from the point of view of the core sys- 
tems, we think it shows a solid line of research that could be exported to other 
areas of mathematical knowledge management. OpenMath technologies are the 
essential tool ensuring the interoperability among systems (even integration in 
some cases). This interoperability has a vertical dimension (from the mediator 
to the kernel systems) as well as a horizontal axis (allowing direct interconnec- 
tion of kernel systems) . The modules can be taken from their sources (as in the 
cases of Kenzo and ACL2), invoked in a remote manner (like the GAP server, 
connected via the SCSCP protocol) or even developed in an ad-hoc way (as our 
Homotopy Expert System). 

Several research lines are still open. The most important ones are related to 
giving more resources to the user to manage the interaction. Moreover, it would 
be also necessary to improve the interaction with the ACL2 system. At this 
moment the queries must be pre-processed; a comfortable way of introducing 
questions about the truth of properties of intermediary objects, dynamically 
generated during a computing session, should be provided. Last, and the most 
difficult one, a meta-language should be designed to specify how and when a 
new kernel system can be plugged in the framework. This capability and the 
necessity of orchestrating the different services suppose a real challenge, which 
will be explored by means of OpenMath technologies. 
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